An embedded computer system typically refers to a computer which is physically embedded within a larger system and whose primary purpose is to maintain some property or relationship between the other components of the system in order to achieve the overall system objective. Embedded computers are now used in a wide variety of systems, such as aircraft, automobiles, appliances, weapons, medical devices, and computer peripheral devices.
Embedded software presents a unique problem and requires a different type of development strategy than other types of software, such as data processing or transaction systems where the computer is at the center of the application. In the computer-centralized system, peripheral equipment with which the computer interacts, such as input, storage, and output devices, is there to serve the needs of the computer and not vice versa. In this type of system, the behavior of the other components of the system are usually known and often designed or chosen with the needs of the computer as the guiding feature. In the embedded system, the computer is typically used to service the needs of the other components; thus, its behavior and design is usually severely constrained by the external process being controlled. Furthermore, the knowledge about the behavior of the physical processes may only be partially known and is often continuous and stochastic and therefore difficult to incorporate into the usually discrete and deterministic computer software model. Instead of having the freedom to select external devices that satisfy the requirements of the computer, the other system components usually dictate the requirements for the embedded computer. Furthermore, the order, timing, and required handling of input events by the computer is typically completely controlled by the other system components, rather than by the software designer. Events that occur in large numbers in a short time or simultaneously must be handled by the computer software in ways that will satisfy the needs and requirements of the larger system. Software requirements for embedded systems are typically allocated during the system engineering process.
Errors must also typically be handled differently in embedded systems than in ordinary computer systems. In most other computer systems, providing information that an error has occurred and discontinuing the processing of the erroneous transaction is satisfactory and perhaps even desirable. A human can then intervene to analyze the error and determine the appropriate recovery procedure. Although the computer system needs to provide corruption procedures (e.g. for erroneous entries in an electronic data base), the decision to make the correction can be handled externally and often off-line. In embedded systems, however, errors and failures must be dealt with immediately, and often the detection and recovery from errors must be automated. The computer must be robust (must continue to operate in a specified manner), even though other components of the system may fail. Also, the other components must typically be made robust in the face of computer errors and failures. Finally, embedded computer software must typically provide facilities to detect and recover from its own errors or, at the very least, to fail gracefully in a way that minimizes damage to the overall system.
FIG. 1 is a block diagram of a conventional embedded system 100. The embedded system 100 is shown to include a central processing unit (CPU) 102 coupled to a random access memory (RAM) 104, a FLASH memory 106, and a read-only only memory (ROM) 108. CPU 102 can read and write from RAM 104 and FLASH Memory 106, in addition to reading data from ROM 108.
FIG. 2 is an illustration of how a conventional "run-from-RAM" embedded application is built. An image 200 of RAM 104 (of FIG. 1) is built along with an application. Image 200 is typically a picture of what RAM 104 will include. Image 200 typically includes code (text) and data. Image 200 is then compressed. Compressed RAM Image 202 is then stored in FLASH memory 106 (of FIG. 1). FLASH memory 106 typically includes an extractor which is utilized in conjunction with the compressed image. An extractor itself is a small executable image which can read compressed RAM image and write uncompressed RAM image to the RAM. During run-time, the compressed RAM Image 202 is then decompressed into RAM
It is often highly desirable to restrict RAM, ROM, and FLASH memory as much as possible in an embedded computer system to reduce cost. The amount of code and data is limited by the size of the RAM in the embedded system.
It would be desirable to optimize the available RAM such that more computer code and data can be utilized with existing amount of RAM. Alternatively, it would be desirable to be able to utilize the same amount of computer code and data with less RAM. The present invention addresses such a need.